1. Field of Invention
The invention relates generally to data communication networks and more particularly to a method of bandwidth management within such a network.
2. Description of the Related Prior Art
FIG. 1 depicts a connection-oriented multiservice network 8. The network 8 is used to establish a call between a source customer premise equipment (CPE) 10 and a destination CPE 12. The source CPE 10 originates a connection with the network 8 at an ingress edge node 14, which propagates the network 8 through a series of intermediate or core nodes 16 to an egress edge node 18 to establish a call to the destination CPE 12. As will be appreciated by those in the art, ingress or egress nodes 14, 18 and intermediate nodes 16 may be routers or switches. These terms will be used interchangeably herein to denote a physical network device that forwards data. The network 8 may consist of an Asynchronous Transfer Mode (ATM) network running Private Network to Node Interface (PNNI) routing protocol, an Internet Protocol (IP) network running Multi Protocol Label Switching (MPLS) and either the Open Shortest Path First—Traffic Engineering (OSPF-TE) routing protocol or the Intermediate System—Intermediate System Traffic Engineering (IS-IS-TE) routing protocol, or the like. Data traffic through network 8 travels over a series of links 20. Each link 20 is basically a communications channel or path. Each node 14, 16, 18 includes a connection admission control (CAC) component 22.
FIG. 2 illustrates a functional block diagram of the components and the operational concepts behind CAC 22. CAC 22 includes a processor 24 that is in communication with a memory 26 and an application module 28. CAC 22 receives a number of inputs, managed and processed by the various CAC elements 24, 26, 28, to process a connection request made by CPE 10. CAC 22 ultimately determines whether a connection request (made by the CPE 12) can be accepted 30 or rejected 32. The inputs include: (a) allocated capacity 34 which represents the total reserved bandwidth by all connections using a given link 20; (b) link capacity 36 which represents the total bandwidth on a given link 20; (c) Quality of Service (QoS) requirements 38 required by the connection; and (d) traffic descriptors 40 which characterize the requirements of the incoming request.
As indicated above, CAC is a function that determines whether an incoming connection request will be accepted or denied and ensures that existing connections are not affected when a new one is established. Using the inputs described above, a CAC algorithm determines whether a new connection setup request can be accepted or should be rejected. This decision is based on the constraint to meet the negotiated QoS requirements of all existing connections as well as of the new connection. Beside this basic function of CAC there is the secondary goal to maximize the system utilization by allowing for a statistical multiplexing gain, i.e. an efficient CAC method should accept as many connections as possible without violating any QoS guarantees. CAC is performed as part of the connection setup process and generally runs as a software module on processor 24. There are a variety of algorithms available to perform admission control.
With respect to an Asynchronous transfer mode (ATM) network, CAC can be defined as the set of actions taken by the network during the call set-up phase to establish whether a virtual channel/virtual path (VC/VP) can be made. With traffic control in ATM networks, there are two classes of QoS parameters which are considered for connection admission control:                (a) Traffic Descriptors—A set of parameters that characterize the source traffic i.e. Peak cell rate, Average cell rate, burstiness and peak duration etc.; and        (b) QoS Requirements—A set of parameters to denote the required quality of service class expressed in terms of cell transfer delay, delay jitter, cell loss ratio and burst cell loss etc.        
Often assumptions are made about the traffic carried in the network. However, CAC can only rely on the traffic parameters negotiated in the service level agreement (SLA) entered into between a client and service provider. In an ATM environment, a typical SLA stipulates QoS objectives and traffic characteristics for the following service categories:                (a) Constant Bit Rate (CBR);        (b) Real Time Variable Bit Rate (rt-VBR);        (c) Non-Real Time Variable Bit Rate (nrt-VBR);        (d) Available Bit Rate (ABR); and        (e) Unspecified Bit Rate (UBR).        
With respect to the PNNI routing protocol, it will be understood by those in the art that this protocol is a virtual circuit routing protocol which is used to route a signaling request through an ATM network. This is also the route on which the ATM connection is set up, and along which the data will flow. The PNNI routing protocol allows for the distribution and updating of a topology database resident at each node in network 8. PNNI supports link state routing in which each node sends information to every other node in the network regarding the state of all of its links (i.e. QoS and reachability information). The PNNI topology state packets (PTSP) containing this information are “flooded” or advertised to the routing database maintained in each node in the network. As will be appreciated by those in the art, topology state information includes the following two parameters:                (a) Non-additive link attributes used to determine whether a given network link or node can meet a requested QoS. Examples of such attributes include available cell rate (ACR), cell rate margin (CRM), variation factor (VF), etc.; and        (b) Additive link metrics that are used to determine whether a given path, consisting of concatenated links and nodes (with summed link metrics) can meet the requested QoS. Examples of such metrics include maximum cell transfer delay (MCTD); maximum cell delay variation (MCDV); maximum cell loss ratio (MCLR); etc.        
There are two kinds of CAC:                (a) Generic CAC (GCAC)—This utilizes a quick and not so accurate algorithm which is used for route selection i.e. it allows a source node to calculate the equivalent bandwidth (EBW) for source routing determination; and        (b) Actual CAC (ACAC)—This utilizes a more accurate algorithm at each node along the path determined using GCAC. The algorithm verifies in real-time the bandwidth availability on a link-by-link basis using an EBW calculation i.e. it is used to guarantee QoS.        
It will be understood by those in the art that the EBW calculation attempts to predict, based on source traffic descriptors, the required bandwidth for a given connection request, while building in a safety of margin to avoid circuit overloading (i.e. the calculation typically determines a suitable bit rate which falls between the average bit rate and the peak rate). The goal in calculating the EBW is to ensure that the sum of the EBW values of the accepted connections does not exceed the capacity of the designated link.
The GCAC algorithm makes use of standardized link parameters that any node can use to calculate the expected CAC behavior of another node, given that node's advertised link parameters and the requested QoS of the new connection request. Referring again to FIG. 1, using the GCAC algorithm, a node presented with a connection request processes the requests as follows:                (a) all links that cannot provide the requested ACR and those whose CLR exceeds that of the requested connection, are “pruned” from the set of possible paths;        (b) from the reduced set of paths, along with the advertised reachability information, a shortest path computation is performed to determine a set of one or more possible paths to the destination;        (c) the possible paths are further pruned by using the additive link metrics, such as delay. One of the acceptable paths would then be chosen; and        (d) the request is then forwarded along the chosen path.        
Using ACAC, each node in the path still performs its own CAC on the routed request because its own state may have changed since it last advertised its state. If the link associated with the node is unacceptable, which is quite possible especially in large networks, to avoid excessive connection failures and retries, PNNI also supports crankback. Crankback is where a connection, which is blocked along a selected path, is rolled back to an intermediate node, earlier in the path. The intermediate node attempts to discover another path to the final destination, using the same procedure as the original node, but uses newer, and hopefully more accurate, network state information.
One technique used in CAC is known as overbooking or oversubscription. Overbooking, which allows the total EBW used by the admitted connections to exceed permissible traffic limits, assumes that some or all active connections are not using the maximum available resources. More specifically, overbooking refers to the exploitation of statistical bandwidth sharing between applications and connections, and uncertainty about the bandwidth demands of various applications. For example, not all connections or applications are active at the same time. Overbooking looks at the bandwidth on a given link which has been reserved, against the actual utilization at a given point in time, and allocates the spare capacity to other connection requests.
Under the classic link bandwidth management model, link bandwidth can be partitioned into multiple pools or shared in a single pool. Each pool can support one or more applications or QoS classes. Three sub-models are available:                (a) Full sharing—uses a single pool which supports all QoS classes. This model offers maximum link efficiency and simplified provisioning and operations;        (b) Full partitioning—each service class (e.g. CBR, VBR-rt, UBR, etc.) is put into its own pool. This model guarantees a defined amount of bandwidth on the link to each service class; and        (c) Hybrid model—some service classes are combined in one pool (e.g. CBR and rt-VBR), while others service classes are in separate pools.In either (a), (b) or (c), link overbooking is achieved by applying an overbooking factor to each pool.        
The example in FIG. 3 represents a full sharing model. Link 41 extending between nodes 42, 44 has an actual capacity of 100 Mbit/sec. A single pool 46 is used to accommodate all service categories from CBR to UBR. Based on historical data detailing the usage of the link an overbooking factor is determined e.g. 3. In the example of FIG. 3, the link capacity of 100 Mbit/sec is multiplied by the overbooking factor of 3 to give a virtual bandwidth availability of 300 Mbit/sec. Multiplying the link capacity by the overbooking factor is a “Classical” approach to overbooking. Edge node 47 making a connection request looks at its topology database, which has received advertised information regarding the available bandwidth of link 41. Because the advertised bandwidth of each node accounts for overbooking, edge node 47 appears to see a link with 300 Mbit/sec less any capacity assigned to calls in progress. GCAC is performed at edge node 47 which does not need to account for overbooking (already accounted for in the inflated pool). ACAC at each node is then performed. The EBW calculated by ACAC at each node also does not account for overbooking. If sufficient capacity is available to meet the QoS requirements of all existing connections as well as of the new connection, the call is admitted. The full sharing model can be problematic in that it treats all classes of data equally by using the same overbooking factor. Further there is no minimum guarantee for any service class.
FIG. 4 depicts the hybrid model in which multiple pools are used. Link 48 has an actual capacity of 10 Mbit/sec. In this case, two bandwidth pools 50, 52 are assigned different service categories, as well as a portion of the link capacity (e.g. pool 50 services CBR and rt-VBR traffic and is assigned 30% of the link capacity, while pool 52 services nrtVBR, ABR and UBR traffic and is assigned 70% of the link capacity). Based on historical data, each pool 50, 52 is assigned a separate overbooking factor (e.g. 3, 4). The allotted portion of the actual link capacity (e.g. 30%×10 Mbit/sec) is multiplied by the assigned overbooking factor (e.g. 3) to give a virtual available bandwidth for each pool (e.g. pool 50 has BW=9 Mbit/sec). The available bandwidth based on the inflated pools is advertised and used by GCAC and ACAC to determine which calls should be admitted. Typically, lower class pools are overbooked more than higher class pools. This ensures that real time data (e.g. video) associated with a higher class pool has a greater probability of being admitted when a connection request is made. The hybrid model is advantageous in that there is a minimum bandwidth guarantee for each pool of classes.
In either a single or multiple pool model, there are problems with an approach in which the actual link capacity is multiplied by an overbooking factor. This methodology is counter-intuitive in that users normally think of bandwidth reservation as it relates to the actual amount of bandwidth used or required for each connection, not in terms of pool sizes. In addition, advertised available link capacity can exceed actual link capacity. Finally, this approach limits the ability to tune the network traffic scheduler to suit the needs of different applications and connections.
In order to overcome the above deficiencies, an “Enhanced” overbooking model was created which incorporated a user-configurable application specific and/or QoS specific overbooking factor which could be applied on a class-by-class basis. The same overbooking factor is used per application/QoS, independent of the number of pools used. The pool size is not enlarged for overbooking purposes i.e. the reservation factor results in a pool size typically equaling the link capacity. As will be explained below, the reserved bandwidth for a given service category is determined by dividing the EBW by an overbooking factor associated with each service category.
An example of the enhanced overbooking model is depicted in FIG. 5. A full sharing model is depicted in which pool 54 handles CBR, rt-VBR, nrt-VBR and UBR traffic. The available bandwidth for the pool (broken down by service/QoS category for ATM PNNI) is advertised to every other node. A connection request requiring a specified service category is received at an edge node. The request is then processed using a GCAC algorithm, resulting in an optimal route through the network that satisfies the bandwidth requirement. ACAC is then applied against each link 56 in the selected route to validate bandwidth availability.
After applying the CAC algorithms, the edge node applies an appropriate overbooking factor to the calculated EBW. The calculated EBW is divided by the per service category overbooking factors to give the actual bandwidth reserved for the application i.e.CBR Reserved Bandwidth=CAC EBW÷CBR Overbooking Factorrt-VBR Reserved Bandwidth=CAC EBW÷rt-VBR Overbooking Factornrt-VBR Reserved Bandwidth=CAC EBW÷nrt-VBR Overbooking FactorUBR Reserved Bandwidth=CAC EBW÷UBR Overbooking Factor
Based on the above calculations, it is determined if the connection for the service category requested can be supported by comparing the available bandwidth for the link/pool with the calculated reserved bandwidth.
The advertised bandwidth does not account for overbooking as in the classic model. It should be noted that different overbooking factors can be used for different service categories, but they should be uniform throughout the network. The use of different overbooking parameters at different nodes/links is not possible, unless the overbooking parameters are propagated throughout the network through network/policy management configuration, signaling during initialization, or advertised available bandwidth flooding.
A problem arises when the nodes operating using the classical bandwidth management model (i.e. multiplying the overbooking factor by the actual link capacity assigned to a pool or pools) must communicate with nodes operating using the enhanced bandwidth management model (i.e. where the edge node GCAC & ACAC EBW is divided by a service category overbooking factor). This may arise where the equipment of different vendors is present in the network. For the purposes of explanation, a network in which respective nodes use the same bandwidth management model will be defined as a homogenous network, while a network in which respective nodes use a different bandwidth management model will be defined as a heterogeneous network. A problem arises because the advertised information from each node results in the storing of inconsistent information in the topology database regarding the available capacity per service category. For example, if a node uses the classical overbooking model, the advertised available bandwidth for the link would equal the actual available bandwidth multiplied by the overbooking factor, whereas a node using the enhanced model would advertise the available bandwidth for the link as the actual available capacity. As a result, the GCAC calculation at a given ingress node could make wrong decisions either by: (a) admitting too many calls resulting in network crankbacks, which would cause connection setup/rerouting delays and waste network resources; or (b) rejecting calls which would otherwise be accepted. Additionally, sub-optimal routing and load balancing could result because of inconsistent information in the topology database.
FIG. 6 highlights the possible outcome of a connection admission request depending on the overbooking model used by the core and edge nodes. In the specific example of FIG. 7, the edge node 58 uses a classic bandwidth management model, while core node 60 uses an enhanced bandwidth management model. The EBW calculated by edge node 58 would not account for overbooking. As well, advertised bandwidth by core node 60 does not account for overbooking. As a result, GCAC performed by edge node 58 may reject calls which would be accepted by core node 60 because the advertised bandwidth appears to be very limited.
It should also be noted that the examples outlined in the above examples assumed that the overbooking factors were uniform throughout the network. This is not always true and can further complicate the connection admission process if the process is unable to account for the different overbooking factors associated with a given link in the network. There therefore exists a need for a solution which will allow nodes in a heterogeneous network, which may also include different overbooking methods and factors, to overcome the connection admission problems outlined above.